1. Field of the Invention
The present invention relates to computer networks and more particularly to facilitating application synchronization with a reservation protocol at a sender without application receiver participation in a computer network.
2. Background Information
A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between network nodes, such as computers. A local area network (LAN) is an example of such a subnetwork. The network's topology is defined by an arrangement of client nodes that communicate with one another, typically through one or more intermediate network nodes, such as routers or switches. As used herein, a client node is a network node that is configured to originate or terminate communications over the network. In contrast, an intermediate network node is a node that facilitates routing data between client nodes. Communications between network nodes are typically effected by exchanging discrete packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
The data packets transferred among the network nodes may include fixed-sized data cells and/or variable-sized data frames. Each data packet typically comprises “payload” data prepended (“encapsulated”) by at least one network header formatted in accordance with a network communication protocol. The network headers include information that enables the client nodes and intermediate nodes to route the packet efficiently through the computer network. Often, a packet's network headers include at least a data-link (layer 2) header and an internetwork (layer 3) header, as defined by the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
In operation, a client node may send a data packet to a network interface of an intermediate network node. Thereafter, the intermediate network node receives the packet and forwards the packet to its next destination. For example, the intermediate network node may perform a layer-2 switching function that simply re-directs the packet from one network interface to another based on the contents of the packet's data-link header. Alternatively, the intermediate network node may perform a layer-3 routing function, or forwarding decision, that selects the most appropriate network interface to forward the packet based on the contents of the packet's internetwork header.
Data packets are used to transport many forms of information, including voice and video information, over networks and subnetworks. For instance, voice information may be transmitted in accordance with the Voice over Internet Protocol (VoIP). VoIP refers to a group of technologies used to transmit voice information over data networks from a source node to a destination node. The source and destination nodes employ voice agents that convert voice information from its traditional telephony form to a form that is suitable for packet transmission. In other words, the source node's voice agent encodes, compresses, and encapsulates the voice information into a plurality of data packets, and the destination node's voice agent performs complementary functions to de-encapsulate, uncompress, and decode the VoIP packets. Examples of voice agents include IP telephones, VoIP gateways, certain private branch exchanges (PBXs), personal computers (PCs) running communication applications, network devices providing voice gateway services, etc. Also, video information may be transmitted in accordance with Video on Demand (VoD) standards known to those skilled in the art in a similar manner. For instance, a VoD content server may supply video data streams to one or more “set-top-boxes”of users. Notably, the use of VoIP and VoD are examples of applications (e.g., at an application levels) that a node within the network may operate. Those skilled in the art will understand that other applications may also be operated at network nodes.
A source node (sender) may be configured to transfer a unidirectional stream of data packets, or a “data flow,” to a destination node (receiver) in a data network. The data flow may comprise, for example, data or voice/video information. The data flow is unidirectional in that data travels one-way from the sender to the receiver. The logical procession of intermediate network nodes that transmit and receive data packets from the sender to the receiver defines the data flow's data path. A first node that is nearer the receiver in the data flow's data path than a second node in the flow is said to be “downstream” from the second node. Likewise, a first node that is nearer the sender in the data flow's path than a second node in the flow is said to be “upstream” from the second node.
Some data flows are associated with a certain level of quality of service (QoS). For example, a data flow's QoS may specify minimum end-to-end latency or bandwidth requirements needed to support the flow. The Resource ReSerVation Protocol (RSVP) is a network-control protocol that enables source and destination nodes to “reserve” the necessary resources to establish the data flow in accordance with the flow's required QoS. RSVP works in conjunction with routing protocols to, e.g., reserve resources along a data flow between the source and destination nodes to establish a level of QoS required by the data flow. RSVP is defined in R. Braden, et al., Resource ReSerVation Protocol (RSVP), Request For Comments (RFC) 2205, which is hereby incorporated by reference as though fully set forth herein.
In a typical arrangement, the sender sends an RSVP Path message identifying itself and indicating the bandwidth needed by the data flow. The Path message proceeds to the receiver following the flow's data path and each intermediate network node may update an optional “Adspec” object of the Path message. The Adspec object contains, inter alia, information about the properties of the data flow, such as available services, delay, and bandwidth estimates. Adspec objects may be generated by senders or by intermediate nodes, and are modified as they travel from one node to another. An Adspec object advertises the possible service parameters composed of the properties of all previous-hop nodes upstream. Namely, the arriving Adspec object is combined with the node's own parameters and service conditions, and then forwarded to the next node. A receiver can use the Adspec information to predict the end-to-end QoS, to choose the most appropriate service and to scale its QoS request according to the current possibilities of the network.
The receiver receives the Path message and may take into account contents of the optional Adspec object in the Path message to determine the specifics of the reservation requests it will generate for the flow. The receiver generates a “request for resources” in the form of an RSVP reservation request (Resv message) which travels hop-by-hop back to the sender. Within the Resv message is a “FlowSpec” object, which contains, inter alia, an indication of a peak expected traffic (e.g., bandwidth) from the sender (Tspec), and the requested traffic value to be reserved (Rspec). At each hop, the corresponding intermediate network node sets aside (“assigns”) sufficient resources to provide the requested bandwidth for the desired data flow. These assigned resources are consequently made available to the data flow so that the data packets of the flow get appropriate QoS treatment (i.e., the data flow is “admitted”).
If sufficient resources are not available, an intermediate network node may “reject” the Resv message (i.e., does not continue forwarding it), generate a reserve error (ResvErr) message, and forward the ResvErr message downstream over the flow to the receiver. The receiver eventually receives the ResvErr message and concludes that the reservation has failed. A receiver whose Resv message has been rejected may attempt to acquire less resources by sending another Resv message requesting less bandwidth, or the receiver may re-attempt later to acquire the resources by re-transmitting another Resv message. Senders are unaffected by this process, and they continue to send Path messages to refresh their state. Notably, PathErr and ResvErr messages are typically sent and processed hop-by-hop by the intermediate nodes along the path between the sender and the receiver, as will be understood by those skilled in the art.
RSVP signaling may be used between a sender and a receiver to perform resource reservation for particular applications requiring QoS guarantees (e.g., VoIP, VoD, etc.). In this case, it is essential that the RSVP reservation establishment be tightly synchronized with the application. For example, VoIP calls should not “ring” the called phone (the receiver) until the RSVP reservation is completed in order to avoid “ghost” rings as will be understood by those skilled in the art. Generally, the application synchronization with RSVP reservation incorporates cooperation of the end-points (i.e., sender and receiver) of both the application and the reservation since both end-points are involved in the signaling of the application and the reservation. An example application synchronization is described in detail in RFC 3312, entitled Integration of Resource Management and Session Initiation Protocol (SIP), updated by RFC 4032, entitled Update to the Session Initiation Protocol (SIP), Preconditions Framework, both of which are hereby incorporated by reference as though fully set forth herein.
In a typical example of application synchronization, e.g., VoIP, a sender may wish to initiate an application session (e.g., call) to a receiver, for which resources need to be reserved to ensure QoS to the session. Accordingly, the sender requests the session is by sending an “offer” to the receiver, and including within the offer an indication that resources ought to be reserved before the session establishment can be completed (i.e. resource reservation is a “precondition”). The receiver may then respond to the offer and provide information details about the session but may put the session establishment on hold until resource reservation is completed. The sender may then trigger reservation establishment (e.g. by sending an RSVP Path message). The receiver may answer the resource reservation request (e.g. by sending an RSVP Resv message). Once the sender receives the answer indicating that the requested resources have been reserved, the sender acknowledges the preconditions to the receiver at the application level signaling. The receiver may then resume establishment of the application session (e.g., and acknowledge the establishment to the sender so that it may also establish the session). In this manner, the application and resource reservation have been successfully synchronized (i.e., the application session has not been established—and for example, the remote phone has not rung—without acknowledging first that the requested resources have been reserved).
In some network environments, however, the receiver is not configured for resource reservation (e.g., RSVP) or is not capable of participating in resource reservation. In many of these situations, a reservation receiver proxy may be located upstream from the receiver (an “application receiver”). Here, the reservation receiver proxy (a “reservation receiver”) performs the resource reservation signaling on behalf of the application receiver. As such, the application receiver is not involved with the resource reservation. Because of this, the application receiver may not participate in the synchronization between the resource reservation and the application establishment. Also, as the reservation receiver is not an end-point for the application, it too may not participate in the synchronization between the resource reservation and the application establishment. In particular, a reservation receiver proxy may be unaware of application level signaling, and thus may be unable to effectively communicate synchronizing messages with the sender. For instance, any admission rejection or errors resulting from the reservation of resources are generally sent to the reservation receiver. According to reservation protocols (e.g., RSVP), the sender may not be notified of this failure. Conventionally, the application receiver would notify the sender of the failure, but as mentioned above, the reservation receiver and application receiver are separate nodes, so this may not be the case (e.g., or possible). It would be beneficial, then, for the sender to synchronize the application with the reservation protocol by itself.
An example of a reservation receiver proxy may be illustrated with reference to VoD applications. VoD content providers may wish to prevent the distribution of VoD content to set-top-boxes (“application receivers”) unless the appropriate resources are reserved (e.g., for admission control), as will be understood by those skilled in the art. Many set-top-boxes, however, may not be configured for resource reservation (e.g., RSVP), and it may be difficult to otherwise “upgrade” the configuration of the boxes. A reservation receiver proxy may be placed upstream from the set-top-boxes to handle the resource reservation, but, as mentioned above, there are problems associated with application synchronization with a reservation receiver proxy.
Various solutions have been proposed for application synchronization at a sender without participation from the application receiver. One such solution consists of the sender attempting to “guess” the status of the reservation. For instance, where a resource reservation request (e.g., Path message) has been sent by the sender, if the sender has not received a response (e.g., Resv message) within a configurable length of time, the sender may assume that the reservation has failed. While this solution allows for application synchronization, it may be slow (i.e., based on the configured length of time sufficient to declare a failed reservation), and may not account for failures after an initial reservation establishment (e.g., an established reservation may be rejected later in response to network element failures), as will be understood by those skilled in the art.
Another proposed solution is to have the reservation receiver proxy generate a “fake” path request error message (e.g., PathErr) to send to the sender in response to receiving a reservation request error message (e.g., ResvErr). In this manner, the “fake” path request error message (“fake” because it is not conventional for a reservation receiver to send path request error messages to the sender in response to reservation failures) may inform the sender of the reservation failure. This approach also suffers from various limitations, including, e.g., a slow response time. For instance, when an intermediate network node between the reservation receiver and sender detects a reservation error, the reservation error message is sent and processed hop-by-hop downstream to the reservation receiver. The reservation receiver may then generate the “fake” path request error message, which is then sent and processed hop-by-hop upstream to the sender. This hop-by-hop processing may be time-consuming, and the solution, therefore, is suboptimally responsive. Also, this solution may be poorly scalable, since where a large network failure occurs, the reservation receiver proxy may be inundated with hundreds or thousands of error messages, resulting in a processing surge and additional delay.
Because tight application synchronization to a reservation protocol is essential (e.g., to interrupt corresponding data flows, etc.), as will be understood by those skilled in the art, minimizing the delays associated with informing the sender of a reservation failure is critical. One such way to minimize the delay with regard to error notifications is the use of a fast failure notification, or a “Notify” feature, as described in RFC 3473, entitled, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions, dated January 2003, which is hereby incorporated by reference in its entirety. In particular, a request (e.g., a Notify request) may be included within the path request or reservation request messages requesting that the intermediate node detecting an error send a fast failure notification along with the conventional error messages (e.g., PathErr and ResvErr, respectively). For example, the reservation receiver may request that a fast reservation failure notification (e.g., for a ResvErr) may be generated and sent to the reservation receiver in response to reservation request errors (i.e., without processing by other intermediate nodes). Also, the sender may request that a fast path failure notification (e.g., for a PathErr) be generated and sent to the sender in response to path request errors.
While the fast failure notification may accelerate the notification of reservation failures to the reservation receiver (e.g., a reservation receiver proxy), the reservation failure notifications are still addressed to, and processed by, the reservation receiver, so it does not help in providing failure notification to the sender. There remains a need, therefore, for a technique that tightly and efficiently synchronizes an application to a reservation protocol at a sender. In particular, a need remains for synchronization where the application level signaling and reservation level signaling terminate at different end-points (i.e., at an application receiver and a reservation receiver), e.g., without application receiver participation.